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O Résumé 

Dans cet article nous exposons les problèmes et les solutions liés à l'in- 
i- H tégration des intergiciels de grilles de PC dans un cloud, en l'occurrence 

^ le cloud libre SlapOS. Nous nous concentrons sur les problématiques de 

recettage qui décrivent l'intégration ainsi que la problématique du confine- 
ment d'exécution qui constituent deux aspects systèmes des architectures 
orientées service et du « Cloud Computing » . Ces deux problématiques dé- 
notent par rapport à ce qui se fait traditionnellement dans les clouds parce 
que nous ne nous appuyons pas sur des machines virtuelles, qu'il n'y a pas 
de centre de données (au sens du cloud). Par ailleurs nous montrons qu'à 
partir du modèle de déploiement initial nous pouvons prendre en compte 
non seulement des applications Web, B2B. . . mais aussi des applications 
grilles ; ici un intergiciel de grilles de PC qui constitue une étude de cas. 



Keywords: Aspects systèmes des architectures orientées service et du Cloud ; 
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1 Introduction 

Le cloud Computing ou « informatique dans le nuage » désigne une forme 
de traitement et un ensemble de ressources informatiques massivement exten- 
sibles, exploités par de multiples clients externes sous forme de services. Plus 
précisément selon le NIST (National Institute of Standards and Technology), 

*Nous remercions en particulier Jean-Paul Smets et Cédric de Saint-Matin de Nexedi pour 
les échanges fructueux au cours de la rédaction de cet article. 
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le cloud Computing est l'accès via le réseau, à la demande et en libre-service 
à des ressources informatiques virtualisées et mutualisées |5T]. La « cloudifica- 
tion », c.à.d. l'intégration d'une application dans un cloud doit s'envisager sous 
les angles : 

- Software as a Service (SaaS) : l'application est découpée en services ; 

- Data as a Service (DaaS) : les données sont disponibles sur le réseau ; 

- Platform as a Service (PaaS) : la plate-forme est granulaire ; 

- Infrastructure as a Service (IaaS) : l'infrastructure est virtualisée. 

C'est en 2009 qu'a eu lieu une réelle explosion du cloud sur le marché avec 
l'arrivée de Google App Engine [53], Microsoft Azuré [T5], IBM Smart Business 
Service [22] et bien d'autres. En mars 2010, IELO, Mandriva, Nexedi et Tiolive 
qui sont quatre éditeurs de logiciels libres se réunissent pour fonder la « Free 
Cloud Alliance » (FCA) dans le but de promouvoir des Clouds Open Source]^] 
elle propose une offre globale réunissant IaaS, PaaS et SaaS, constituée de tous 
les composants libres nécessaires aux applications Progiciel de Gestion Intégré 
(ERP), gestion de la relation client (CRM) ou gestion de la connaissance (KM). 

En 2011 le projet Resilience, retenu dans le cadre du 12ème appel à pro- 
jets du fonds unique interministériel (FUI-12) fut lancé. Ce projet regroupe 
des universitaires (Paris 13, Institut Télécom, INRIA) et des industriels dont 
Nexedi, Sagem Morpho, Wallix, Vifib. Ce projet comporte une partie « pros- 
pective amont »qui est relatée dans cet article. 

Le projet Resilience se base sur le cloud libre SlapOS [2ïï| , dont les principales 
caractéristiques sont les suivantes, en première approximation : 

- il ne repose pas sur de la virtualisation ; 

- il ne repose pas sur des centres de données ; 

- il reprend en partie une architecture de grille de PC |13| : des machines à 
la maison abritent des services et des données ; un « maître » contient un 
annuaire des services et les services eux mêmes ; 

- la propriété d'interopérabilité s'obtient « à la Grid'5000 »c.à.d en dé- 
ployant le démon SLAPGRID sur des noeuds d'Amazon, d'Azuré. . .puis 
en installant sur ces nœuds les bonnes versions logicielles. Cela évite d'uti- 
liser par exemple Libcloud qui est une librairie servant à l'intéropérabilité 
des clouds. . . mais rien ne garantit que chacun des clouds tourne la même 
version de Libcloud ce qui est généralement une condition nécessaire au 
bon fonctionnement global. 

Le problème général que nous adressons est le suivant : comment faire en 
sorte qu'un service de Grille de PC soit déployable depuis n'importe où, n'im- 
porte quand (à la demande) et sur n'importe quels dispositifs (smartphoncs, 
tablettes, PC. . . ). Une première option est d'intégrer tel quel dans le nuage les 
intergiciels les plus utilisés à ce jour comme BOINC et Condor. C'est l'objet 
de cette étude. La deuxième option serait de repenser les interactions entre les 
composants usuels d'une grille de PC en terme de paradigme issus du Web 2.0. 
C'est l'objet d'un autre travail que nous ne commentons pas plus ici. 

1. Free Cloud Alliance : http ://www. freecloudalliance.org/press/fca-Press.Contact/news- 
free-cloud-alliance 
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Dans cet article, nous illustrons nos contributions à partir de notre expé- 
rience de « cloudification »de l'intergiciel de grille de PC BOINC dans SlapOS 
ce qui fait ressortir les points clés architecturaux de SlapOS, les principaux 
concepts liés aux systèmes d'exploitation qui sont mis en jeux. Les difficultés 
résident dans le fait que BOINC est organisé différemment par rapport aux ap- 
plications Web qui sont le « fond de commerce »de SlapOS. La question est donc 
de savoir si le modèle SlapOS est suffisamment général pour « cloudifier » aussi 
des intergiciels de grilles. Nous ouvrons également une discussion sur le modèle 
de confinement d'exécution et sur son couplage avec SlapOS. 

Ainsi, dans cet article nous présentons une méthodologie d'intégration de 
BOINC dans le nuage SlapOS ainsi qu'une première réflexion quant au confi- 
nement d'exécution dans SlapOS. Si l'on veut qu'un utilisateur accepte de voir 
tourner une partie d'une application sur son propre smartphone ou tablette, 
il est nécessaire de lui garantir que l'application ne pourra pas être intrusive. 
Ce problème n'est pas propre aux grilles de PC, mais il est d'importance et sa 
solution est directement liée à la manière d'intégrer une application, ici BO- 
INC. L'état actuel de développement de SlapOS n'inclut pas de solution pour 
ce problème. 

L'organisation de l'article est donc le suivant. Dans le paragraphe [2] nous 
introduisons les concepts clé de SlapOS, les problèmes traités et notre position- 
nement. Le paragraphe [3] décrit les expériences et ce que nous en retirons en 
terme d'organisation future de SlapOS. Le paragraphe [4] conclut cet article. 

2 Enjeux scientifiques et techniques 

2.1 Présentation générale de SlapOS 

SlapOS (Simple Language for Accounting and Provisioning Operating Sys- 
tem |26j ) est un système d'exploitation distribué et Open Source qui fournit 
un environnement permettant d'automatiser le déploiement des applications, 
tout en incluant des services de comptabilité et la facturation grâce à l'ERPS 
(Progiciel de Gestion Intégré libre basé sur la plate-forme Zope et le langage 
Python) . Basé sur la devise que « tout est processus » , SlapOS combine le Grid 
Computing (en particulier BonjourGrid [31 E|) et les techniques des ERP pour 
fournir des composants IaaS, PaaS et SaaS, tout cela à travers un démon ap- 
pelé SLAPGRID. Les forces de SlapOS sont la compatibilité avec tout système 
d'exploitation, particulièrement les systèmes GNU Linux ; la compatibilité avec 
toutes les technologies logicielles, le support de plusieurs infrastructures (IaaS) 
différentes et plus de 500 recettes disponibles pour les applications grand public 
telles que LAMP (Linux Apache MySQL PHP). 

La cloudification d 'intergiciels de Grid Computing ne faisait donc pas partie 
du cœur du métier des personnes ayant introduit la solution SlapOS. Cet article 
démontre que BOINC peut avantageusement s'intégrer au cloud SlapOS et nous 
montrons les efforts nécessaires tout en soulignant les concepts clés qui rendent 
cette intégration aisée. L'objectif est donc d'étudier et de montrer que l'on peut, 
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« en un clic », instancier, configurer des familles de logiciels et les déployer sur 
Internet. 

2.1.1 Concepts clés de SlapOS 

L'architecture de SlapOS est constituée de deux types de composants : Sla- 
pOS Master et des SlapOS Nodes. Le SlapOS Master indique au SlapOS Node 
quel logiciel doit être installé et aussi quelle instance d'un logiciel spécifique 
sera déployé ; il agit comme un annuaire centralisé de tous les SlapOS Nodes ; 
il connaît l'emplacement où les logiciels sont situés ainsi que tous les logiciels 
qui y sont installés. En se basant sur la date de démarrage, la date d'arrêt (ce 
qui représente un intervalle d'exécution) et aussi sur les ressources utilisés par 
une application, le Master peut faire la facturation pour chaque utilisateur. Le 
SlapOS Node peut être hébergé sur un ou plusieurs datacenters ou encore sur 
un ordinateur local, il communique avec le SlapOS Master à l'aide du SLAP 
Protocol et renseigne de façon périodique sur l'état des ressources dont il dis- 
pose. Le rôle du SlapOS Node est d'installer et d'exécuter des processus tandis 
qu'un Master a pour rôle d'allouer les processus aux SlapOS Nodes. 

SlapOS Node s'exécute sur un noyau appelé « SlapOS kernel », il est consti- 
tué d'une distribution minimale du système GNU Linux, d'un démon nommé 
SLAPGRID, d'un environnement d'amorçage des applications (technologie Buil- 
dout) et de Supervisord qui sert à contrôler les processus en cours d'exécution. 

Pour introduire les concepts clés, nous discutons, de manière générale, de 
l'installation d'un nouveau logiciel dans SlapOS. Ainsi SLAPGRID reçoit du 
Master une requête pour installer un logiciel, celui-ci télécharge alors le fichier de 
description du logiciel que l'on appelle « Buildout profile »et lance le processus 
d'amorçage Buildout qui va installer le logiciel. Buildout est un système de 
compilation développé en python et utilisé pour créer, assembler et déployer des 
applications composées de plusieurs pièces dont certaines peuvent être non-basé 
sur Python. Il permet de créer une configuration Buildout et de l'utiliser pour 
reproduire/cloner le logiciel plus tard. Il est capable d'exécuter un programme 
C, C++, ruby, java, perl, etc. Il joue un rôle que l'on peut rapprocher à celui 
de GNU Make. 

SLAPGRID peut aussi recevoir du Master une requête demandant de dé- 
ployer une instance d'un logiciel, il utilise alors Buildout pour créer tous les 
fichiers (fichiers de configurations et programmes à exécuter) nécessaires, à l'aide 
de Supervisord lance le démarrage de l'application. 

Un logiciel sur un SlapOS Node est appelé « Software Release »et il est 
constitué de l'ensemble des programmes et composants nécessaires à son fonc- 
tionnement. A partir d'un Software Release, on peut créer plusieurs instances du 
logiciel correspondant qu'on appelle « Software Instance » . Le concept de Soft- 
ware Instance renvoie à l'idée selon laquelle un serveur peut exécuter de façon 
indépendante un nombre élevé de processus d'un même logiciel. Puisque ces pro- 
cessus utilisent la même mémoire partagée, l'empreinte mémoire est surchargée 
et permet d'exécuter une autre instance avec des ressources mémoires minimales, 
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contrairement au principe de virtualisation. Il est donc possible d'exécuter sur 
un SlapOS Node plus de 200 instances d'un même logiciel. Dans le cas de Tiolive 
Services, 200 ERP5 peuvent être exécuté sur un CPU dual core standard. 

Une partition SlapOS ou « Computer Partition »peut être vue comme un 
conteneur léger ou un enceinte clos |24| . il fournit un niveau d'isolation raison- 
nable (inférieur à celui d'une machine virtuelle) basé sur la gestion des utilisa- 
teurs et des groupes par le système d'exploitation hôte. Chaque Partition est 
constituée d'une adresse IPv6, une adresse IPv4 locale (privée), une interface 
TAP [T7] dédié nommée « slaptapN », un nom d'utilisateur de la forme « slapu- 
serN »et un répertoire dédié (généralement /srv/slapgrid/slappartN). SlapOS 
est configuré pour fonctionner avec IPv6, l'un des avantages étant la possibilité 
d'avoir un très grand nombre de partitions. 

Une partition est destinée à contenir une seule application, celle-ci peut être 
une Software Instance quelconque ; la Software Instance est alors accessible de- 
puis l'adresse IP de la partition. Seul l'utilisateur slapuserN a les droits de 
lecture et d'écriture sur les données de la partition N, de même les processus 
de la partition sont exécutés et contrôlés par l'utilisateur slapuserN. Toutes ces 
règles permettent d'assurer une certaine sécurité et évite des accès non auto- 
risés venant par exemple des processus d'une autre partition. Puisque SlapOS 
s'exécute en mode administrateur (root) il a donc la possibilité d'accéder et de 
paramétrer la partition N sans avoir besoin d'être slapuserN. 

Généralement, SlapOS regroupe les environnements d'exécution des logi- 
ciels sous forme de stack (pile). Le concept de stack dans SlapOS représente 
un environnement de base pour le déploiement d'une classe d'application bien 
précise. Nous pouvons prendre l'exemple des applications Web basées sur PHP, 
une stack (actuellement nommée LAMP) permettra alors d'installer l'ensemble 
des composants nécessaires pour l'exécution de ces applications (MySQL, PHP, 
Apache, etc). La recette associée permettra de démarrer les services. L'objectif 
ici est de fournir une méthode généralisant le déploiement des applications de 
même type tout en simplifiant la création de leurs profils Buildout. Toute la 
complexité est renvoyée au niveau de la stack. Dans le même ordre d'idée, les 
composants (Apache, PHP, etc) sont portés de manière séparée et indépendante 
dans SlapOS ce qui permet d'utiliser le même composant dans plusieurs stacks 
ou Software Release. 

Le fonctionnement de SlapOS repose aussi autour des technologies externes 
Buildout et Supervisord. Afin d'automatiser le déploiement des applications, 
SlapOS a recours à la technologie Buildout en exploitant les concepts de parts 
et de recette. Une part représente tout simplement un objet, un paquet python 
ou un programme manipulé par Buildout. La part est référencée par son nom 
et sera installée dans le répertoire de l'application à laquelle elle est associée. 
Pour chaque part est définie une recette qui contient sa logique de gestion ainsi 
que les données qui serons utilisées. Une recette est un objet qui sait comment 
installer, mettre à jour ou désinstaller une part précise. Dans le cadre de SlapOS 
on dispose d'un annuaire de recettes nommé slapos.cookbook qui contient près de 



5 



105 recettes pour le déploiement d'applications et de composants. Le paquet sla- 
pos.cookbook peut être consulté sur http ://pypi.python.org/pypi/slapos.cookbook/ 

2.2 Confinement d'exécution, sûreté de fonctionnement 

La première idée de conception de SlapOS est de considérer que tout est 
processus ainsi, le système est basé sur la collection d'un ensemble de processus 
qui communiquent entre eux à base de services internet utilisant des protocoles 
de communications. Les processus sont surveillés par l'outil Supervisord qui 
permet de les relancer en cas de problèmes. Nous n'allons pas plus loin ici sur 
ces questions de tolérance aux pannes car cela est en dehors du cadre mais ces 
préoccupations sont abordées dans le projet Resilience. SlapOS combine des 
hébergements non fiables, des serveurs dédiés à moindre coût et des clouds à 
domicile pour atteindre une fiabilité de 99,999%. SlapOS est en réalité beaucoup 
plus fiable que les approches traditionnelles du cloud puisque, en sélectionnant 
des sources indépendantes, il peut survivre en cas de force majeure : grève, 
tremblement de terre, coupures d'électricité, etc. 

3 Description des expériences 

3.1 Introduction 

Supposons que vous souhaitiez qu'une de vos machines s'intègre dans Sla- 
pOS. La démarche générique est la suivante : 

1. télécharger et/ou installer une image SlapOS ; 

2. créer un compte utilisateur sur le master (http :/ /vifib.net) ; 

3. amorcer cette image (configuration automatique du réseau, formatage du 
disque local si besoin c.à.d. si on souhaite installer les partitions SlapOS 
sur ce disque) ; 

4. lancer la commande slapprepare afin de configurer les partitions SlapOS, 
enregistrer le nœud au niveau du master (le login et le mot de passe du 
compte utilisateur précèdent sont requis) et démarrer le démon SLAP- 
GRID ce qui autorise la communication entre le nœud et le master ; 

5. la dernière opération consiste à demander à l'administrateur du master 
l'enregistrement du/des applications à installer sur le nœud. Il faut fournir 

une url de la forme http : / / git . erp5.org/gitweb/ slapos.git/blob/refs/heads/grid- 
computing : / software /boinc / software. cfg. 

3.2 Articulation des fichiers de recettage 

L'intégration des applications à SlapOS passe par l'écriture des profils Buil- 
dout, constitués principalement du fichier software, cfg, qui va ensuite faire la 
référence à tous les autres fichiers requis. Dans le cadre de l'intégration des ap- 
plications de type BOINC (applications qui tournent avec BOINC) nous avons 
conçu l'architecture présentée à la figure [ï] 
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Figure 1 - Présentation de l'arborescence du projet BOINC pour SlapOS. 



BOINC est une plate-forme de calcul distribué. Pour l'utiliser, on peut créer 
un projet puis fournir une ou plusieurs applications, des fichiers de données et 
les fichiers de configuration pour l'exécution de l'application sur sa plate-forme. 
Il convient donc de créer une stack que nous avons nommée BOINC et qui 
va permettre d'installer de configurer un environnement d'exécution pour les 
applications BOINC dans SlapOS. Ainsi la création d'un projet et l'intégration 
d'une ou plusieurs applications à exécuter se réduira simplement à la définition 
des paramètres permettant de personnaliser notre projet et au téléchargement 
des fichiers utiles. Cet aspect nous semble un effort raisonnable. 

BOINC est subdivisé en trois applications distinctes que nous discutons 
maintenant. 

3.2.1 BOINC Server 

L'installation du serveur est plus complexe. Sur la Figure [T] nous avons 
appelé tout simplement cette installation « BOINC », elle est donc constitué 
de la stack nommée « BOINC », d'un composant nommée « BOINC »et d'une 
application exemple nommée aussi « BOINC ». 

BOINC est une application avec de nombreuses dépendances pour sa com- 
pilation, toutefois, la plupart de ses composants sont déjà disponible dans Sla- 
pOS. Le profil du composant BOINC permet donc de compiler BOINC dans 
SlapOS en y intégrant tous les autres composants nécessaires pour cette com- 
pilation. Notons sur la Figure [T] aussi l'utilisation des options -disable-manager 
et -disable- client qui permettent de désactiver la compilation du client et du 
manager. 

La stack BOINC intervient à deux niveaux ici, pendant la compilation et 
pendant le déploiement. La compilation fait référence au fichier buildout.cfg de 
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la stack, tandis que le déploiement de la stack fait référence au fichier instance- 
mariadb.cfg (pour installer MySQL dans une partition) et instance-boinc (pour 
installer BOINC, Apache, PHP, SVN, etc dans une autre partition). Elle est gé- 
nérique c'est-à dire qu'elle peut être utilisée pour l'installation ou le déploiement 
de plusieurs projets et applications BOINC différentes sans aucune modification 
supplémentaire, il suffira de lui passer les configurations appropriées. 

Le software BOINC est une application exemple appelée à être modifiée 
pour adapter l'application BOINC qu'on souhaite installer. Il est constitué du 
fichier software. cfg qui est utilisé pendant la compilation et permet de créer 
un software Release BOINC contenant la stack et le composant BOINC et de 
télécharger le binaire et les fichiers de/des applications à installer. Le dossier 
contient l'objet input qui contient les données pour des applications à exécuter. 
Toutefois ces fichiers peuvent se situer sur un emplacement ou un serveur distant, 
ils seront alors téléchargés pendant la compilation. Le dossier templates contient 
les templates d'entrées/sorties à utiliser pour la configuration du WORKUNIT 
de l'application, il peut être personnalisé. 

Pour le déploiement de BOINC Server, nous avons ajouté à slapos.cookbook 
deux recettes : 

- La recette slapos.cookbook :boinc qui permet de déployer un projet BOINC 
vide ; elle est utilisée directement dans la stack. 

- La recette slapos.cookbook :boinc-app qui permet de déployer une applica- 
tion dans une instance BOINC existante. Il est donc possible de déployer 
plusieurs applications pour un même projet, en appelant successivement la 
même recette slapos.cookbook :boinc-app pour les différentes applications. 

Nous présentons maintenant des échantillons de fichiers de configuration de 
parts Buildout permettant de compiler et de déployer un projet BOINC muni 
de l'application exemple upper_ case, qui met en majuscule un texte fourni. La 
part boinc- application (qui se trouve dans le fichier software. cfg) télécharge le 
binaire et collecte les paramètres du WORKUNIT qui sera crée, elle est utilisée 
pendant la compilation. Sa forme est la suivante : 

1. #Download Boinc Application Binary and configure project 

2. [boinc-application] 

3. recipe = hexagonit . recipe . download 

4. url = ${boinc : location}/libexec/examples/upper_case 

5. download-only = true 

6. filename = upper_case 

7. #Application configuration 

8. app-name = upper_case 

9. version = 1.0 

10. exec-extension = 

12. platform = x86_64-pc-linux-gnu 

13. #Work Unit: wu-name without blanc space: wu-number number of work unit 

14. wu-name = simpletest 

15. wu-number = 1 

Dans cette description on remarque que nous spécifions, à la ligne 3, la recette 



8 



qui permet de télécharger le binaire spécifié via l'URL de la ligne 4. Les autres 
lignes concernent le type de plate-forme requis (ligne 12) et le nom du WOR- 
KUNIT (ligne 14) ainsi que le nombre de WORKUNIT (ligne 15) à affecter à 
l'application spécifiée à la ligne 8. 

La part boinc-app présentée ci-dessous (et contenue dans le fichier boinc- 
app.cfg) est utilisée pendant le déploiement ; elle hérite (ligne 3) de BOINC Ser- 
ver contenu dans la stack et est basée sur la recette slapos.cookbook :boinc-app 
(ligne 4). Elle utilise les fichiers et paramètres définis dans le fichier software. cfg 
et plus particulièrement ceux de la part boinc- application. Entre les lignes 6 et 17 
il ne s'agit que d'un transfert des paramètres définis dans le fichier software. cfg. 

1. #Deploy a Boinc application in existing boinc server instance. 

2. [boinc-app] 

3. <= boinc-server 

4. recipe = slapos . cookbook: boinc . app 

5. binary = ${boinc-application: location}/${boinc-application: f ilename} 

6. #app-name should be unique (for ail app deployed in a boinc instance) 

7. app-name = ${boinc-application: app-name} 

8. version = ${boinc-application: version} 

9. platform = ${boinc-application:platf orm} 

10. extension = ${boinc-application: exec-extension} 

11. dash = ${dash: location}/bin/dash 

11. #templates 

12. template-result = ${template_result : location}/${template_result : f ilename} 

13. template-wu = ${template_wu: location}/${template_wu: f ilename} 

14. #Work Unit 

15. wu-name = ${boinc-application: wu-name} 

16. wu-number = ${boinc-application: wu-number} 

17. input-file = ${template_input : location}/${template_input : f ilename} 

Il suffira de mettre plusieurs parts de ce type dans le fichier boinc-app. cfg 
pour déployer autant d'applications dans le serveur, tout en prenant soin de 
donner des noms différents à ces parts ainsi qu'aux options app-name, wu-name. 
Les paramètres de personnalisation du serveur BOINC sont passés directement 
pendant le déploiement de l'instance à travers les paramètres d'instance appelés 
slapparameter. Il s'agira du nom du projet, du nom de la base de données, etc. 

3.2.2 BOINC Client 

Le client représente un nœud de calcul, il sera donc possible d'utiliser Sla- 
pOS pour avoir des ressources supplémentaires pour les calculs. Sur la figure [T] 
nous avons appelé cette partie boinc-client, elle est constituée d'un composant 
nommée « boinc-client »et de son application nommée aussi « boinc-client ». 
Nous avons ajouté à slapos.cookbook la recette slapos.cookbook :boinc-client qui 
permet de déployer une instance d'un BOINC Client. L'url et la clef du compte 
utilisateur crée sur le serveur BOINC doivent être fournies à l'instance à travers 



9 



les paramètres d'instance appelés slapparameters pour permettre la connexion 
entre le serveur et le client BOINC. 

3.2.3 BOINC Manager 

Nous n'avons pas intégré cette application à SlapOS car étant entièrement 
graphique elle doit être installé sur un ordinateur personnel, c'est une application 
de bureau. 

3.3 Vers un nouveau mécanisme de confinement d'exécu- 
tion dans SlapOS 

3.3.1 Utilisation du MAC (Mandatory Access Control) 

Le MAC est une forme de contrôle d'accès différent du traditionnel DAC 
(Discretionary Access Control). Dans les systèmes DAC, les permissions sur les 
objets sont laissées à la discrétion du possesseur. La philosophie du MAC est 
d'appliquer une politique de sécurité sur un système à laquelle même le super 
utilisateur (root) doit se plier. La base d'une politique MAC est le Type Enfor- 
ccmcnt (TE) [8J. Dans le TE, les objets du système sont « typés »et on définit 
les interactions permises entre ces différents types. Au dessus du TE, il est pos- 
sible d'implémenter des modèles de politiques de sécurité type MLS (MultiLevel 
Security) [ÏÏ] . En pratique, le TE délimite les interactions systèmes potentielles 
d'un programme (même si il s'exécute sous l'identité du super utilisateur). Nous 
allons utiliser SELinux |25| qui propose une implémentation du TE intégrée au 
noyau Linux. 

3.3.2 SELinux 

SELinux est une implémentation de TE basée sur l'architecture FLASK 
|20| . Les entités du système sont décomposées en sujets et objets. Les sujets 
sont les entités « actives »(par exemple les processus). Les objets sont les entités 
« passives »(par exemple les fichiers). Toutes ces entités se voient attribuées 
un label. Une politique de sécurité définit les interactions permises entre un 
label de type sujet et un autre de type objet. La granularité de ces interactions 
est au niveau de l'appel système (lecture, écriture, exécution, transition). Une 
politique peut être appliquée en mode « targeted » , c'est à dire sur certains 
services seulement (essentiellement ceux exposés sur le réseau) ou « strict », 
c'est à dire sur tous les services. 

3.3.3 Pourquoi SELinux ? 

SlapOS propose de déployer des services à l'intérieur de partitions. Du point 
de vue de la sécurité, une partition est composée d'un ou plusieurs processus 
et des fichiers associés (configuration, librairies, logs etc.). Le tout est déployé 
dans un répertoire particulier du système. Le problème est qu'une intrusion sur 
une partition (suite par exemple à une faille sur un service, un mot de passe 
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faible ou une erreur de configuration) suivie d'une escalade de privilèges com- 
promet toutes les partitions du système (une fois les privilèges administrateur 
obtenus, toutes les partitions de la machines physique sont accessibles). Ce type 
de faille n'est pas propre à SlapOS mais à tous les systèmes basés sur le DAC 
|18| . Les systèmes de Cloud traditionnels contournent le problème en ajoutant 
une couche de virtualisation qui (entre autre chose) fait office de mécanisme 
de confinement. Cependant cette couche supplémentaire augmente la surface 
d'attaque du système. GrSEC est un autre outil de contrôle d'accès mandataire 
comparable à SELinux mais SELinux est intégré au noyau Linux et il est plus 
« supporté »que GrSEC. Nos avons donc choisi de travailler avec SELinux. 

3.3.4 Intégration de SELinux dans SlapOS 

L'idée est d'utiliser SELinux pour : 

- limiter les interactions des partitions avec le système de base ; 

- Interdire les interactions entre partitions. 

L'expérimentation pourra se faire en deux temps. Une première phase se- 
rait de faire tourner SELinux en mode « targeted »sur les partitions. Chaque 
partition opère avec une identité dédiée et exécute des binaires situés sur le 
système de base. Prenons comme exemple une partition ayant le rôle de serveur 
et tournant sous l'identité webOl, une politique générale pourrait être : 

- webOl peut exécuter le binaire httpd ; 

- webOl peut lire sa configuration ainsi que les pages qu'il doit servir dans 
la partition dédiée (objets de type fichiers situés dans le répertoire de la 
partition) ; 

- webOl peut écrire ses logs dans la partition. 

Toutes les autres interactions sont interdites pour les processus tournant sous 
l'identité webOl. L'étape suivante est de passer la politique en mode « strict »pour 
protéger non plus seulement les services déployés par SlapOS mais le service de 
déploiement lui même. En conclusion, la démarche expérimentale est donc : 

1. Intégrer la phase de labellisation du système de fichier lors de l'instancia- 
tion du disque local pour les partitions SlapOS ; 

2. Faire une politique en mode « targeted »pour un service déployé ; 

3. Automatiser le déploiement des politiques lors de l'instanciation du service 
dans une partition SlapOS ; 

4. Créer une politique pour le système SlapOS lui même ; 

5. Automatiser l'installation de cet politique au déploiement de SlapOS ; 

6. Passer SELinux en mode strict. 

4 Conclusion 

Dans cet article nous avons montré comment « cloudifier »l'application BO- 
INC dans le cloud SlapOS. Les concepts clés permettant l'intégration sont les 
notions de partitions, de stack, de recette. Bien que conçus initialement pour 
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un usage pour les applications Web, ils sont suffisamment généraux pour au- 
toriser l'intégration de BOINC à un coût de développement relativement bas. 
Il s'agit avant tout d'identifier des tournures d'esprit permettant d'intégrer des 
composants logiciels communicants. 

Le nombre de lignes à écrire pour l'intégration est de l'ordre de 200 et toutes 
les démarches préopératoires (déclaration de projets, définition d'un utilisa- 
teur. . . ) et postopératoires (re-compilation, déploiement) sont inchangées par 
rapport à une application Web. 

Pour le futur, nous prévoyons un test d'interopérabilité, par exemple en 
prenant des clients dans Azuré. Le modèle de déploiement de SlapOS, où nous 
pouvons déployer nos propres OS pour le cloud facilite cette tâche. Enfin, des 
décisions concernant le couplage des politiques SELinux doivent être prises à 
partir des pistes que nous avons isolées dans cet article. 

L'objectif général de ce travail est d'offrir des services Desktop Grid à la 
demande, sur tous les appareils, sans discernement, c'est à dire sur les smart- 
phones, tablettes et ordinateurs de bureau. En outre, le service devrait pouvoir 
être déployé par un non informaticien « en un seul clic »et la gestion du sys- 
tème ne devrait pas être limitée aux administrateurs système, mais largement 
ouverte. Il s'agit, de notre point de vue, de conditions nécessaires pour que les 
grilles de PC puissent survivre dans les nouveaux environnements logiciels du 
Web et soient réellement ouverts, accessibles au plus grand nombre de cher- 
cheurs et d'ingénieurs et non plus réservés à une communauté d'une dizaine de 
projets les utilisant. 
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